I'm sorry, I couldn't resist.

Also 👍

I expect a song or prayer at the end containing "and all my references were counted down to zero"

GREAT! Thumbs up! Although I won't be able to attend Euruko :'( I'll wait for the videos.

p.d: do you plan to do it for Baruco as well? hehehe. :P

👍 I would love to see a comparison to JVM GC (is Ruby better at GC ?)

👍 especially interested in code optimization, e.g. two methods with equal outcome but massive gc
impact

Interesting proposal. +1.

👍

I'd be interested in this talk, provided you make a clear distinction between Ruby and MRI. Ruby garbage collection != MRI garbage collection. For example Rubinius implements a Generational Garbage Collector that is a lot more sophisticated than MRI's simple mark-and-sweep: http://rubini.us/doc/en/garbage-collector/

+1

@leocassarani that seems clear to me, too. I'll try and avoid sowing any confusion.

+1

(especially if you would also compare the MRI garbage collector to JRuby / Rubinius)

Maybe add a short segment on http://en.wikipedia.org/wiki/Waste_minimisation and how the useful strategies for this change with different GCs.

I'd be happy to help you show graphs, logs, tuning and impl details for the various JVM garbage collectors, which of course JRuby takes advantage of.

👍

@headius, when you show the difference of GC time between JVM and YARV, audience will realize that how YARV's bytecode processing is fast. You'd better let invokedynamic and IR go live first? :)

👍

@headius I think you would be a much better candidate to do this talk :) Yes, all information is more than welcome, I only have a superficial knowledge of what's going on in the JVM,

@nahi That would be worth it if it helped encourage more work on speeding up 1.9.3's GC :)

I have noticed a disturbing trend, too...1.9.3 GC is slower than 1.9.2, and 2.0.0dev is slower than that. Things seem to be moving in the wrong direction :(

@elisehuard When you start putting together info for your talk (assuming it is accepted) let me know.

@headius,

I have noticed a disturbing trend, too...1.9.3 GC is slower than 1.9.2, and 2.0.0dev is slower than that.

Besides 2.0.0dev, 1.9.3 should be "slower" than 1.9.2 from "total GC time" point of view. That's what lazy sweeping, that is for improving GC response time, as you know :) I don't think that "things seem to be moving in the wrong direction" but possible affected users should care about the change. @elisehuard will help you understand by pres.? :)

I'll try to dig up the benchmark results, but what I noticed was 1.9.3 and 2.0.0dev took longer to complete object/garbage-heavy benchmarks than previous versions. It was not simply a matter of total CPU time or total GC time, but total end-to-end completion time of a single-threaded benchmark that created a lot of garbage.

Ah, I remembered that you tweeted something about it. @authorNari would be interested in it. I heard that a script that keeps lots of long-live objects may face worse GC throughput time than expected but IIRC your (or @evanphx's?) PoC GC benchmark was different example.

...Sorry for trolling this thread...

+1

@nahi The test is in the gc_tests project on my github, and does indeed include a mix of young and old objects. I fear that "lots of long-lived objects may be more common than people realize. Rails, for example, is not small in memory.

If I didn't already: +1 for this talk :-)

👍

+1

Perhaps these old proposals could be closed? I am auditing still-open issues that mention me and it would be nice for this to not be here. 😀